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Abstract 

Today's Internet naming scheme, the Domain Name System [28], im- 
plicitly assumes that applications want to reach an address, where the 
address signifies location in the network topology. Typically, appli- 
cations desire either information or functionality, and do not often 
know the best network location that satisfies their needs. We argue 
that current efforts to efficiently enable new services such as mobility, 
group communication, resource discovery, service location, caching, 
etc. have been greatly hampered by the lack of a flexible naming 
system and the inability of the name resolution process to affect data 
routing decisions. Significant effort is spent in creating independent, 
but similar infrastructure for each situation. 

This paper presents the design and implementation of an inten- 
tional network naming architecture, where applications describe what 
they are looking for (i.e., their intent), not where to find it. In this 
architecture, name resolvers can also route messages to the eventual 
destinations, leading to an integrated approach to resolution and rout- 
ing. We present efficient data structures for maintaining intentional 
names based on attribute-value tuples, efficient algorithms for name 
lookups, and discovery protocols for disseminating name information 
among resolvers and end-hosts. We analyze the performance of the 
algorithms and present measurements of the system implementation, 
which show that our architecture is practical and feasible. We also de- 
scribe a sample application — a mobile, wireless camera application 
for remote surveillance — demonstrating the utility of the architecture 
in supporting mobility, group communication, service location and 
data caching. 

1 Introduction 

In the last several years, we have seen the Internet grow phe- 
nomenally in terms of number of users, size, traffic, and ap- 
plications. Thus, it now faces a different set of demands and 
challenges than it did originally — in particular, a demand for 
better support for the efficient deployment and performance 
of new services. People and the applications they use are de- 
manding features such as mobility, caching, load balancing, 



replication, service location, resource discovery, and group 
communication. While many of these problems are receiv- 
ing attention in the networking community, we believe that 
existing proposals to solve these problems tend to be overly 
specific or unnecessarily complex. 

We argue that current efforts to efficiently enable new ser- 
vices have been greatly hampered by the inflexibility of the 
naming system and the inability of the name resolution pro- 
cess to affect data routing decisions. Significant effort is spent 
in creating independent, but similar infrastructure for each sit- 
uation. We observe that for a number of these services and 
applications, a more flexible and integrated naming and rout- 
ing architecture will greatly simplify and often solve the hard 
problems that arise, because at a fundamental level, all these 
problems are made easier with a "level of indirection" in the 
way messages are routed in the network. Motivated by these 
observations, we strive to provide the right, general level of 
indirection via the name resolution system. 

Today, most network naming schemes such as the Domain 
Name System (DNS) [28] implicitly assume that applications 
want to reach an address, where the address signifies location 
in the network topology. Typically, applications desire either 
information or functionality, and do not often know the best 
network location that satisfies their needs. We therefore argue 
that what is needed is an intentional naming scheme and res- 
olution architecture in which applications describe what they 
are looking for, not where to find it. Furthermore, we advo- 
cate that the name resolvers also participate in message rout- 
ing based on intentional names, thereby integrating name res- 
olution and routing, which until now have been kept separate 
in the Internet. This integration, implemented by including 
application payload with the name resolution request 1 , allows 
the "late binding" (i.e., binding at packet delivery time) be- 
tween the network routes to the end nodes and the name that 
maps on to those nodes. This enables users and applications 
to track changes easily, including host mobility, dynamic re- 



Name resolvers treat the application payload as opaque data. 



sources, and changing data at network nodes. 

The main contribution of our work is the design and imple- 
mentation of an Intentional Name System, called INS. In this 
paper, we describe three aspects of INS in detail: 

• Intentional naming scheme. We present a naming 
scheme where applications express the characteristics of 
the information or nodes they want to reach as query ex- 
pressions in a restricted query language. In particular, 
we show that significant benefits can be obtained using 
an exact match operator in the language, which enables 
resolution based on matching variables in an incoming 
name (i.e., attributes) to one among a set of values by the 
resolvers. These variables are under application control 
and not pre-defined. The resolvers can perform resolu- 
tion without understanding the semantics of specific ap- 
plications. 

• Intentional Name Resolvers (INRs). We present a res- 
olution architecture composed of a self-organizing net- 
work of INRs to resolve intentional names and route mes- 
sages. Our architecture incorporates efficient algorithms 
for name lookups based on exact matches and a low- 
latency discovery protocol for disseminating name infor- 
mation among end nodes and resolvers. We analyze these 
algorithms and discuss experimental performance results 
from our implementation to justify the feasibility of our 
ideas. 

• Application architecture. We demonstrate the INS ap- 
plication architecture by describing the design and imple- 
mentation of a mobile, wireless camera application for 
remote surveillance over INS. We discuss how this appli- 
cation easily leverages INS's API and automatic support 
for mobility, group communication, service location and 
data caching, gaining these advantages from INS with- 
out any other pre-installed support for these different ser- 
vices. 

A key feature of our architecture is its potential for incre- 
mental and easy deployment in the Internet, without changing 
or supplanting the existing Internet service model. We achieve 
this by designing the resolvers to communicate with each 
other tunneled over an IP network, using well-understood In- 
ternet routing protocols to route messages between resolvers. 
Our experience with this demonstrates that a variety of new 
services can be deployed effectively by our extensions to Inter- 
net naming and resolution, without requiring active, general- 
purpose computation in either the routing [38] or naming [40] 
subsystems of the Internet architecture. 

We hasten to note that the INS architecture presented in this 
paper is not intended for a network as large as the global In- 
ternet. Rather, it is intended for networks on the order of few 
hundred or few thousand nodes (e.g., inside an administrative 
domain), much like schemes for intra-domain unicast (e.g., 



OSPF [29]) or multicast routing (e.g., DVMRP [11]). We are 
actively developing a wide-area architecture to complement 
our intra-domain INS architecture, which will integrate INS 
with extensions to DNS. 

The rest of this paper describes our design rationale 
and presents the details of INS. Section 2 discusses the 
INS architecture, describing the intentional naming scheme, 
name lookup algorithm, entity discovery protocol and self- 
organization protocol. It also describes various optimizations 
and benefits of INS. Section 3 discusses the INS API and our 
mobile camera application. Section 4 discusses implementa- 
tion details and Section 5 presents the analysis of the algorithm 
and the results of performance experiments based on our im- 
plementation. We survey related work in Section 6 and then 
conclude. 

2 System Architecture 

The design of the INS architecture is motivated by our desire 
to enable applications to express the destination (and source) 
of their messages using an intentional name that describes the 
intent of the application, rather than a specific end-point. To- 
wards this goal, we introduce the name-specifier, which is 
used in the message header instead of the traditional source 
and destination addresses, to describe the intent of the appli- 
cation. Section 2.1 describes the components of the name- 
specifier, how they are assembled into an intentional name, 
and the wire representation of the name-specifier. 

The name-specifiers are resolved into their corresponding 
network locations by Intentional Name Resolvers or INRs. 
INRs communicate with each other and applications in an ar- 
bitrary topology of tunnels overlaid on the IP network. Rather 
than having statically configured relationships, as is common 
in other overlay networks [13, 17], a self-organization proto- 
col is used to spawn and terminate INRs, and maintain neigh- 
bor relationships; this protocol is described in Section 2.4. 

To learn and share information about names, the INRs com- 
municate via a name discovery protocol. The protocol uses 
periodic updates to convey name information, and uses trig- 
gered updates for fast changes. In addition, we discuss a novel 
optimization to implicitly learn about names by inferring in- 
formation from message headers. These issues are detailed in 
Section 2.3. 

The central activity of INRs, of course, is to resolve name- 
specifiers into their corresponding network locations. INRs 
support two methods of name resolution: early binding, in 
which the INR returns a handle to the end-hosts (typically a set 
of IP addresses), and late binding, in which the INRs forward 
data on behalf of the application, deferring the binding of the 
name-specifier to the end-host until just before the data is de- 
livered to its final destination. Late binding enables highly dy- 
namic name bindings, since the application is never left with a 
stale binding even if bindings change while the message is in 



transit. We focus our attention on the late binding case in this 
paper. Section 2.2 describes the INR namespace, the name- 
tree — a data structure used to store name information, and the 
algorithm used to look up intentional names in the name-tree. 

2.1 Name- Specifiers 

There are many ways to implement intentional names; in INS 
we use query expressions called name-specifiers that replace 
traditional addresses in packet headers. Our design decisions 
are based on the idea that the name-specifier should provide a 
flexible and powerful, yet efficient method of selecting names; 
we were also motivated by the desire to keep name-specifiers 
simple and easy to understand. 

The two main concepts of the name-specifier are the at- 
tribute and the value. An attribute is a category in which an 
object can be classified, for example its 'color.' A value is the 
object's classification within that category, for example, 'red.' 
Attributes and values are free-form strings that are defined by 
applications; name-specifiers do not restrict applications to us- 
ing a fixed or predefined set of attributes and values. Together, 
an attribute and its associated value form an attribute-value 
pair. 

Name-specifiers are a hierarchical arrangement of attribute- 
value pairs. The pairs are arranged in a tree such that a pair 
that is dependent on another is a descendant of it. For in- 
stance, in the example name-specifier shown in Figure 1, it 
only makes sense to talk about a building called the White- 
house if you are referring to the city of Washington, so the 
attribute-value pair building=whitehouse is dependent on 
the pair city=washington. Pairs that are orthogonal to each 
other, but dependent on the same pair, are siblings in the 
tree. For example, a digital camera's data-type and resolu- 
tion can be selected independently of each other, are mean- 
ingful only in the context of the camera service. Therefore, 
the pairs data-type=picture and resolution=640x480 
are orthogonal. This hierarchical arrangement narrows down 
the search space during name resolution, and makes name- 
specifiers easier to understand. 

A simpler alternative would have been to construct a hier- 
archy of attributes, rather than one of pairs. This would result 
in building being directly dependent on city, rather than 
city=washington. However, it is also less flexible; our cur- 
rent hierarchy allows child attributes to vary according to their 
parent value. For example, country=us has a child that is 
state=virginia, while country=canadahas a child that is 
province=ontario. 

To include it in the header to describe the source and desti- 
nation of a message, the name-specifier has a wire representa- 
tion as shown in Figure 2. This string-based representation 
was chosen to be readable to assist with debugging, in the 
spirit of SMTP [35], HTTP [16], NNTP [23], etc. Levels of 
nesting are indicated by the use of brackets ( [ and ] ), and at- 
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Figure 1 : A graphical view of an example name-specifier. The 
hollow circles are used to identify attributes; the filled cir- 
cles identify values. The tree is arranged such that dependent 
attributes are descendants, and orthogonal attributes are sib- 
lings. This name-specifier describes a public-access camera 
in the Oval office. 
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Figure 2: The wire representation of the example name- 
specifier shown in Figure 1, with line-breaks and extra spacing 
added to improve readability. 



tributes and values are seperated by an equals sign (=). The 
arbitrary use of whitespace is permitted anywhere within the 
name specifier, except in the middle of attribute and value to- 
kens. 

In addition to exact value matches, name-specifiers also 
permit wildcard matching of values. To do this, the value 
is simply replaced by the wildcard token, a star (*). Thus 
to construct a name-specifier that refers to all public cam- 
eras providing 640x480 pictures in the Whitehouse, not just 
the one in the Oval Office, an application replaces the value 
oval-office with '*' in the name-specifier shown in Fig- 
ures 1 and 2. The application also sets the anycast/multicast 
flag to choose whether the packet should be sent to all cam- 
eras or just any one camera. We are currently investigating the 
use of inequality operators (<, >, <, and >) to provide range 
selection operations in name-specifiers. 

2.2 Name Resolution and Message Routing 

The central activity of an INR is to resolve name-specifiers to 
their corresponding network locations. When a message ar- 
rives at an INR, the INR performs a lookup on the destination 
name-specifier in its name-tree. The lookup returns informa- 
tion that includes a set of "routes" to next-hop INRs, as well 



as the IP addresses of final destinations. If the application has 
chosen to use early binding by setting the early-binding flag, 
the INR simply returns the IP addresses to the application. If 
the application desires late binding, the INR forwards the mes- 
sage to the next-hop INRs without making any changes to the 
name-specifiers or data. This forwarding continues until the 
message reaches its final destinations, providing a late bind- 
ing between the destination name-specifiers and their respec- 
tive IP addresses. 



Name-trees. Name-trees are a data structure used to store 
the correspondence between name-specifiers and name-info 
records. The principal information that the name-info records 
contain are the routes to the next-hop INRs and the IP ad- 
dresses of potential final destinations. The records also store 
additional information such as the metric for the routes and 
the expiration time of the record. 

Not surprisingly, the structure of a name-tree bears a close 
resemblance to a name-specifier. Like a name-specifier, it con- 
sists of alternating levels of attributes and values; but unlike a 
name-specifer there can be multiple values per attribute, since 
the name-tree is a superposition of all the name-specifiers the 
INR knows about. Each of these name-specifiers has a pointer 
from each of its leaf-values to a name-info record. Figure 3 de- 
picts an example name-tree, with the example name-specifier 
from Figure 1 in bold. 



Name lookups. The Lookup algorithm, shown in Figure 4, 
is used to retrieve the name-info records for a particular name- 
specifier n from the name-tree T. The main idea behind the 
algorithm is that a series of recursive calls reduce the candi- 
date name-info set S by intersecting it with the name-info set 
consisting of the records pointed to by each leaf-value. When 
the algorithm terminates, S contains only the relevant name- 
info records. 

The algorithm starts by initializing S to the set of all possi- 
ble name-info records. Then, for each attribute-value pair of 
the name-specifier, it finds the corresponding attribute in the 
name-tree. If the value in the attribute-value pair is a wild- 
card, then it computes S' as the union of all name-info records 
in the subtree rooted at the corresponding attribute, and inter- 
sects S with S' . If not, it finds the corresponding value in the 
name-tree. If it reaches the leaf of either the name-specifier or 
the name-tree, the algorithm intersects S with the name-info 
records pointed to by the corresponding value. If not, it makes 
a recursive call to compute the relevant set from the subtree 
rooted at the corresponding value, and intersects that with S. 

Section 5.1 analyses this algorithm and discusses the exper- 
imental results of our implementation. 




Figure 3: A partial graphical view of an example INR name- 
tree. The name-tree consists of alternating layers of orthog- 
onal attributes and their possible values. Leaf-values con- 
tain pointers to all the routes they correspond to. The part 
of the name-tree corresponding to the example name-specifier 
shown in Figure 1 is in bold. 



2.3 Name Discovery 

INRs learn about names by participating in a name discovery 
protocol with their neighbor INRs and end-nodes. Through 
this peer-to-peer protocol, the associations between name- 
specifiers and name-info records propagate throughout the 
INR network and to end-nodes and applications. These asso- 
ciations are obtained from the name-tree using an extraction 
algorithm, and are then disseminated either during periodic or 
triggered updates. The INRs also employ a novel optimization 
to learn new names, which we call inference. The following 
paragraphs detail these topics. 

Name extractions. Since the INR name-tree is a superposi- 
tion of all the name-specifiers the INR knows about, extracting 
a single name-specifier to advertise is non-trivial. The EX- 
TRACT algorithm, shown in Figure 5, is used to retrieve the 
name-specifiers for a particular name-info record r from the 
name-tree T. The main idea behind the algorithm is that a 
name-specifier can be reconstructed while tracing upwards to 
the root of the name-tree from each pointer to a name-info 



LooKUP(n,T) 
S := the set of all possible name-info records 
for each attribute-value pairp := (n a ,n v ) in n 
T a := the child of T such that 
name(T a ) = name(n a ) 

if Tl v = * > wildcard matching 

S':=0 

for each T v which is a child of T a 
S' := S' U all of the name-info records in the 
subtree rooted at T v 
S:=SnS' 

else l> normal matching 

T v := the child of T a such that 
name(T^) = name(n„) 
if T v is a leaf node or p is a leaf node then 

S := S n the name-info records of T v 
else 
S := S n Lookup^, T„) 
return(5) 



Figure 4: The LOOKUP algorithm. This algorithm looks up 
the name-specifier n in the name-tree T and returns all appro- 
priate name-info records. 



EXTRACT(r,T) 
set all PTRs in the tree rooted at T to null 
T.PTR := a new, empty name-specifier 
for each v which is a parent value element of r 

Extract-Trace^, null) 
return(T.PTR) 



E> something to graft onto 
E> something to graft 



Extract-Tracers) 
if w.PTR != null 
if s != null 
graft(s, w.PTR) 

else > nothing to graft onto; make it 

?;.PTR := a new attr. -value pair consisting of 
this value and its parent attribute 

II S != null \> something to graft 

graft(s, w.PTR) 
EXTRACT-TRACE(parent value of v, v.PTR) 



Figure 5: The EXTRACT algorithm. This algorithm extracts 
and returns the name-specifier for the name-info record r in 
the name-tree T. EXTRACT-TRACE implements most of the 
functionality, tracing up from a leaf-value until it can graft 
onto the existing name-speficier. 



record, and grafting on to parts of the name-specifier that have 
already been reconstructed. 

All the values in the name-tree, T, are augmented with 
a "PTR" variable, which is a pointer to the corresponding 
attribute-value pair in the name-specifier being extracted. Ini- 
tially, all the PTRs are set to null, since they have no cor- 
responding attribute-value pairs; the root pointer (T.PTR) is 
set to point to a new, empty name-specifier. Then, for each 
parent value of r, the algorithm traces upwards through the 
name-tree. If it gets to part of the name-tree where there is a 
corresponding attribute-value pair (v. PTR != null), and it has 
a name-specifier subtree to graft on to (s != null), it does so. 
If not, it creates the corresponding part of the name-specifier, 
sets v.PTR to it, grafts on s if applicable, and continues the 
trace with the parent value of v and the new subtree. Figure 6 
illustrates the progress of the algorithm. 

Updates. INRs use updates to keep each other informed of 
the name-specifiers they know about. Triggered updates occur 
when an INR receives an update from one of its neighbors 
(either an INR or an application) that causes a change in its 
name-tree; this allows new advertisments to propagate through 
the network rapidly. Periodic updates are used to prevent the 
aging out of data that has not changed and to refresh entries in 
neighboring INRs. This combination of periodic and triggered 
updates enables us to treat the disseminated name state as soft 
[9], and therefore does not require a fully reliable transport 
protocol such as TCP. 



INRs use the Bellman-Ford algorithm [4] to calculate the 
shortest distance to the end-nodes. Unlike traditional routing 
protocols that use the algorithm [20, 27], the INS architecture 
does not require unique end-nodes — if a name is advertised 
from more than one location, the algorithm computes the best 
overall metric based on INR hop count. 

Inference. Here, INRs learn about new names by passively 
observing the headers of messages they receive. When an INR 
receives a message that is travelling from a to b, in addition to 
forwarding it towards b, it also adds a name-info record to the 
name-tree for a, noting that its next-hop INR is the INR the 
message arrived from. The metric for the name-info record is 
found by looking at the up-counter field in the header, which is 
incremented as the message travels from source to destination. 
Learning about routes via inference is especially important for 
learning about clients who have just made a request in large 
networks. Using inference, only the INRs on the path from 
the source to the client need to learn about this client. 



2.4 INR Self-Organization 

INR machines are not static, pre-configured servers, but are 
dynamic, in order to reflect load, node locality and the need for 
efficient routing in the face of mobility. We achieve this with a 
self-organization protocol that spawns INRs as needed, forms 
neighborhoods of active nodes, and kills existing INRs when 
they are no longer useful. Being highly distributed with no 





Figure 6: An illustration an in-progress execution of the EX- 
TRACT algorithm. The subtree s is being grafted onto u.PTR. 
The traced paths and PTRs are shown with dotted lines; the 
PTR being used and graft are shown in bold. 



centralized control, it has the potential to scale with increasing 
load and perform well even when failures or partitions occur. 

INRs run on machines in the general computing infrastruc- 
ture of an organization; typically there is a pool of machines 
that are candidate INRs, of which a subset are active at any 
time. The administrators of these machines can limit the 
amount of processing and communication expended by INR 
on a node. This means that nodes can join and leave the active 
INR set at any stage based on external conditions 

Bootstrapping is based on a list of candidate INRs that is 
available to applications (e.g., from the DNS). If an applica- 
tion detects that none of these candidate nodes are active, it 
can spawn an INR on any of these nodes. This is especially 
useful for efficient ad hoc mobile networking in remote loca- 
tions, such as a meeting room or network isolated from the 
rest of the Internet. 

Neighbors are dynamically maintained by a SO- 
LICIT/ACCEPT protocol. The neighbor relationship in 
our design is explicitly designed to be symmetric. This 
simplifies routing by eliminating the need to deal with 
uni-directional paths and allowing the use of inferred routes. 

As the load increases on a resolver, additional INRs are 
spawned on other candidate nodes, and INR functionality can 
be terminated at any time (e.g., if the load is too light or 
heavy). Our design uses a probabilistic birth/death algorithm 
with local load monitoring for this; this algorithm is similar 
to the one described by Amir et al. in the context of an Ac- 
tive Service framework [1]. It has the desirable property that 
all nodes make autonomous decisions to achieve good global 
behavior. 

We have currently not implemented the self-organization 
protocol, but expect to do so shotly. 

2.5 Benefits and Optimizations 

In this section we discuss some of the benefits that our archi- 
tecture offers and the optimizations one can make because of 
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Figure 7: A name-tree with a cached copy of packet data. The 
cached data is indicated by a '$'. 

them. These include caching, group communications, mobil- 
ity, and resource discovery. 

Caching. The main difficulty with implementing middle-of- 
the-network caching in today's Internet is that packets aren't 
named in a way that is both application-independent and 
reusable. For example, an IP address / TCP port number / TCP 
sequence number can be used to identify a packet in the mid- 
dle of an HTTP transfer, but it isn't reusable since there is no 
permanent mapping from sequence number to the source data. 
To make this reusable, one has to sacrifice the application- 
independence of the name by interpreting the HTTP transfer. 
Intentional names give each packet a reusable, application- 
independent name — the source name-specifier. Thus, adding 
caching requires only two modifications to the INR behavior: 

1 . When transmitting a packet, make a copy of its data and 
store a pointer to it under the route entry for the source 
name-specifier in its name-tree. 

2. When looking up the destination name-specifier of a 
packet, check to see if there is a cached copy of the data 
which could be sent instead. 

An illustration of a name-tree from such an INR is shown in 
Figure 7; in addition to the regular route, it also has a cached 
copy of the data. The cache-TTL field of the packet indicates 
how long the data is valid and is also stored in the name-tree. 
INRs may also inform their neighbors that they have a cached 
copy by using regular name advertisements. 

Group communication. Despite the development of multi- 
cast routing (detailed in [10, 11, 3, 12, 24]) and a proposal 
for anycast routing ([32]), unicast transmission remains the 
predominant communication paradigm of the Internet. In con- 
trast, INS makes no assumption that any service resides on any 
particular host, or even on only a single host. In particular, our 
name lookup algorithm uses set operations to determine the 
correct routes, rather than just looking for a single route. This 
allows INS to easily support features akin to multicast and 
anycast, with unicast merely being a special, single-host case 
of either of those. 

Since intentional names represent a service rather than an 
end-point, multiple hosts can announce that they are provid- 
ing the service. Rather than just choosing the best route to- 
wards a name-specifier, the INRs maintain a list of all of the 



routes towards that service. When the INR forwards a packet, 
it checks the anycast/multicast flag of the packet header to de- 
cide how to handle it. If the flag is set to anycast, it forwards 
it to the neighbor with the best metric; if it is set to multi- 
cast, it forwards it to all neighbors for whom it has a route. 
This anycast/multicast feature is useful for implementing mir- 
rored or redundant services and load balancing. It is further 
enhanced by the ability to use wildcards in intentional names, 
as described in Section 2.1. 



Mobility. Mobility in the Internet relies upon a complex 
Mobile IP scheme that involves the deployment of Home 
and Foreign Agents [33]. This compexity arises because of 
the overloading of the IP address as both a permanent end- 
point identifier, and a topologically sensitive address that must 
change as a host moves through the network. Another possi- 
ble solution is to use a naming system to provide a perma- 
nent identifier, and then update the naming system as the host 
moves. DNS cannot easily accomplish this since it is statically 
configured, though dynamic updates in the DNS improve the 
situation [42]. 

INS, on the other hand, is explicitly designed for rapid 
updates. Periodic updates ensure that the name-tree main- 
tains long-term consistency, while triggered updates allow an- 
nounced changes to occur almost immediately. Thus when a 
host moves, all it has to do is announce the intentional names 
for the services it provides to its new neighbors, and these are 
quickly propagated through the INR network. This feature 
can also be used to implement service mobility, which can be 
used to move services from one machine to another (perhaps 
to allow upgrades), or even among many machines (perhaps to 
have a service follow a particular person). To accomplish this, 
the hosts just coordinate the passing of the intentional name 
announcement among each other. 



Resource discovery. Intentional names are inherently a 
method of resource discovery: rather than specifying the host 
it wants to access, users and applications convey their intent by 
supplying an intentional name that describes the service they 
desire. INRs learn about the services that exist in the network 
via the name discovery protocol, and either pass this informa- 
tion on to applications in the form of a handle, or simply pass 
the application data on to the service provider on its behalf. 
The passing of a handle is similar to the operation of the Ser- 
vice Location Protocol (SLP) [41, 34]. INS is designed for a 
similar scale network, but operates without the use of a cen- 
tralized Directory Agent or any other single point of failure. 



3 Using the System 

3.1 Application Programming Interface 

The INS API provides a flexible framework for developing 
applications that take advantage of its application-controlled 
name resolution. It provides functions for creating and manip- 
ulating intentional names (name-specifiers), advertising and 
discovering new services, and leveraging INS support for 
caching, anycast, group communication and late binding. 

In the application, a name-specifier is represented as pairs 
of attribute and value objects with an implicit assumption that 
the resolution operator is an exact match or wildcard opera- 
tor 2 . The API provides functions to link these objects and con- 
nect them to other similar objects to form a complete name- 
specifier. 

INS provides name-specifier functions to: 

• add a query clause, 

• retrieve a component, 

• search for a query clause, 

• generate a readable text representation, and 

• compare another name-specifier to it. 

After creating a name-specifier describing a service, the ap- 
plication can advertise the new service to the network using 
an INS function. Similarly, to discover new services, the ap- 
plication can use an INS function to find out whether services 
matching a given name-specifier have been discovered; if they 
have, it may communicate with them by using INS functions 
to construct the appropriate name-specifiers. 

The INS API also allows applications to enable caching, 
simply by setting the length of time the message should be 
cached by intermediate nodes. Applications choose whether 
anycast or multicast is used by setting a flag in the message 
header. 



3.2 A Mobile Camera Application 

In order to evaluate the utility of our system for enabling appli- 
cations that are difficult to create in today's Internet, we have 
implemented a mobile camera application for remote surveil- 
lance using INS. We present an example scenario from it here 
to reinforce system concepts and demonstrate how an appli- 
cation uses the API. The camera service consists of a num- 
ber of physically mobile nodes equipped with cameras, each 
running a transmitter application, and a number of nodes run- 
ning receiver applications displaying images from the remote 
cameras. Figure 8 shows the network topology used in this 
example. 

The application uses name-specifiers with four orthogonal 
attributes: service (svc) identifies that it is a camera appli- 
cation, location (loc) describes its physical location, entity 



2 As we incorporate other operators such as range checks, this assumption 
will change. 
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Figure 8: Network topology for the camera application exam- 
ple. INRs a and b run a receiver, c runs a transmitter, and r is 
an intermediate INR without an application. 
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Figure 9: Name-tree at INR r after Step 2. 

(ent) indicates whether it is a transmitter (xmt) or a receiver 
(rev), and node is a unique identifier for each node. 

The application operates as follows: First, receivers learn 
about available camera locations via discovery protocol up- 
dates sent by transmitters. Then users of the receiver appli- 
cation may request an image from a particular location. The 
request message will be routed to the transmitter(s) that can 
service a request for that location, independent of their net- 
work location and the transmitter that announced the service. 
Inference is used by intermediate nodes to create a path back 
to the receiver. Finally, the transmitter sends back a response 
containing the image requested. 

The sequence of INS events in an example operation is: 

1. The transmitter on c is started, and informs c's INR 
that it wants to receive all messages destined to it. 
The transmitter registers a route to it for name-specifier 
[svc=camera] [loc=home] [ent=xmt] [node=c] and 
also tells the INR to announce this to its neighbors. 

2. INR c sends a triggered-update to INR r with 
[svc=camera] [loc=home] [ent=xmt] [node=c] in it. 
INR r updates its name-tree to include the new name, as 
shown in Figure 9. It then sends the update to INRs a and 
b, which update their name-trees. 

3. When the receiver on a is started, it asks INR 
a to let it know about any name-specifiers match 
[svc=camera] [ent=xmt] . 

4. INR a, which has received an update from INR 
r for [svc=camera] [loc=home] [ent=xmt] [node=c] 
passes this name-specifier to the receiver, which informs 
the user that a new camera has been discovered at home. 

5. The user requests an image from home. The receiver 
sends a message with destination name-specifier: 
[svc=camera] [loc=home] [ent=xmt] 

and source name-specifier: 



Figure 10: Name-tree at INR r after Step 7. 

[svc=camera] [loc=home] [ent=rcv] [node=a] . 
Note that the node attribute is omitted from the desti- 
nation name-specifier, since the receiver only wants an 
image from camera at home, and doesn't care which 
particular node supplies the image. 

6. While handling the message, INR a infers that 
[svc=camera] [loc=home] [ent=rcv] [node=a] (the 
source name-specifier of the message) is coming from 
the application receiver. INR a then forwards it to INR r. 

7 '. INR r knows to forward this message to INR c since 
its name-tree (Figure 9) contains this route information. 
Using inference as before, INR r knows that the source 
name-specifier of the message must be in the direction of 
INR a, and adds this information to its name-tree. This 
is shown in Figure 10. 

8. Upon receiving the message from INR r, INR c passes 
it to the transmitter. INR c also adds an inferred 
route for the source name-specifier. The transmit- 
ter notices this request and sends back a message 
with the requested image, destination name-specifier 
[svc=camera] [loc=home] [ent=rcv] and source 
name-specifier: 

[svc=camera] [loc=home] [ent=xmt] [node=c] . 
Note that the node attribute is omitted from the desti- 
nation name-specifier. This can be used to send it to all 
receivers who request the image, not just node a. INS 
uses this to perform group communication. 

9. Node c receives the message from the transmitter appli- 
cation and forwards it to INR r. Similarly, r forwards the 
message to a, which then passes it on to the receiver ap- 
plication. All these nodes know the route to the receiver 
because of the inferred routes acquired during the flow of 
the request message from the receiver to the transmitter. 



4 Implementation 

The INS architecture has been fully implemented and tested 
using the mobile network of cameras as the test application. 
Our implementation of INR is in Java, to take advantage of 
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Figure 1 1 : The INS message format. 

its easy cross-platform portability. User applications are not 
constrained to be written in Java. 

In this section, we present the implementation details of two 
key aspects of INS: the architecture of an INR node, and the 
packet formats for intentional names. 

INR node architecture. INRs use UDP to communicate 
with each other. At an INR, the Node is the manager of all net- 
work resources and running applications at a resolver. It main- 
tains the NameTree that is used to resolve an intentional name 
to its corresponding route information, a ForwardAgent to 
forward messages, and a NodeListener that receives all in- 
coming packets. In addition, there are two useful applica- 
tions that run at each INR: an EntityDiscovery applica- 
tion, which implements the name dissemination protocol, and 
a NetworkManagement application that provides a graphical 
interface to monitor and debug the system and view the name- 
tree. 

The INR implementation consists of approximately 5000 
lines of Java code. Using the INS API, applications are rel- 
atively easy to develop. For example, the camera application 
was implemented in less than 1000 lines of Java, of which over 
60% was for the user-interface and image display. 

Packet format of intentional names. Figure 1 1 shows the 
INS packet format for intentional names. Because name- 
specifiers are of variable length, three pointers (pi, p2, p3) 
point to the start of the source name-specifier, destination- 
name-specifier and data fields of the message. INR nodes do 
not process application data. 

The IP field contains the IP address of the source node, 
and is used by applications to perform "early binding" of in- 
tentional name to address, id is a monotonically increasing 
32-bit unique ID for the message, used in conjunction with IP 
to detect routing loops. In addition to the standard TTL field, 
messages contain a ct field that counts up from zero at each 
INR. When an INR performs route inference, it uses ct as a 
hint to initialize the metric for the route. 

The af field indicates whether the destination specified by 
the d-ns field is meant to be an individual ("any") entity or 
a group ("all") of entities. cTTL field stores the TTL of (op- 
tional) cached data. 
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Figure 12: A uniformly grown name-tree. Note that d = 
(tree depth) /2 = 1 for this tree. 

5 Performance Analysis and Evalua- 
tion 

In this section, we analyze performance of the INS name 
lookup algorithm and present the results of our experiments 
with the lookup algorithm and name discovery protocol. Our 
results are encouraging and demonstrate the practical feasibil- 
ity and deploy ability of INS. 

5.1 Name Lookup Performance 

Analysis. Since INS scalability with load is a major con- 
cern, it is important to analyze the performance of the lookup 
algorithm as the demands on it increase. While many of the 
tasks involved in resolving a name take the same amount of 
time (e.g., copying the data, transmitting it over the network), 
the time to perform a name lookup depends on a number of 
factors. It is therefore important to determine the worst-case 
run-time of the algorithm. 

To simplify the analysis of our lookup algorithm, we 
assume that name-specifiers grow uniformly in the following 
dimensions (illustrated in Figure 12): 



One-half the depth of name-specifiers 
Range of possible attributes in name-specifiers 
Range of possible values in name-specifiers 
Actual number of attributes in name-specifiers 



In each invocation, the algorithm iterates through the at- 
tributes in the name-specifier, finding the corresponding at- 
tribute and value in the name-tree and making a recursive call. 
Thus, the run-time is given by the recurrence, 

T(d)=n a -(t a +t v +T(d-l)), 

where t a and t v represent the time to find the attribute and 
value respectively. For now, assume that it takes time b for the 
base case such that: 

T(0) = b 

Setting t = t a + t v and performing the algebra yields: 

T(d) = n a -(t + T(d-l)) 
ni-l 



1 



t + n d ~ l ■ b 



@(n d a -(t + b)) 



If linear search is used to find attributes and values, the run- 
ning time would be: 

T(d) = @(nj-(r a +r v +b)), 

because t a oc r a and t v oc r v in this case. 

However, using a straightforward hash table to find these 
reduces the running time to: 

T(d)=@(n d a -(l + b)) 

Implications. From the above analysis, it seems that the 
n d factor may suffer from scaling problems if d grows large. 
However, both n a and d, will scale up with the complexity of 
a single application associated with the name-specifier. There 
are only as many attributes or levels to a name-specifier as 
the application designer needs to describe the objects that are 
used by their application. Consequently, we expect that that 
n a and d will be near constant and relatively small; indeed, 
our mobile camera application has this property. 

The cost of the base case, b, is the cost of an intersection 
operation between the set of route entries at the leaf of the 
name-tree and the current target route set. Taking the intersec- 
tion of the two sets of size si and s 2 takes @(max(si, s 2 )) 
time, assuming the two sets are sorted (as in our implementa- 
tion). In the worst case the value of b is on the order of the size 
of the universal set of route entries (0(|<7 1)), but is usually sig- 
nificantly smaller. Unfortunately, an average case analysis of 
b is difficult to calculate analytically since it depends on the 
number and distribution of names. 

Experiment. To experimentally determine the name lookup 
performance of our (untuned) Java implementation of an INR, 
we created a number of randomly constructed name-trees, and 
timed how long it took to perform 1000 random lookup op- 
erations on the tree. The name-tree and name-specifiers were 
chosen to be uniform with same parameters as the analysis in 
Section 5.1. We varied n, the number of distinct names in the 
tree, and measured lookup times. We performed our experi- 
ment on an off-the-shelf PC with an Intel Pentium II processor 
running at 450 MHz with 512 KB cache and 128 MB RAM. 
The machine was running Red Hat Linux 5.2, and the code 
was compiled and run under Sun's Java version 1.1.7. 

We fixed the parameters at r a = 3, r v = 3, n a = 2, 
and d = 3, and varied n from 1 to 2500. Our results are 
shown in Figure 13. For this name-tree and name-specifier 
structure, our performance went from a maximum of about 
1060 lookups per second to a minimum of 220 lookups per 
second. We did see occasional large variations in similar tri- 
als, and conjecture that it is a consequence of quirks in Java's 
memory allocation. We also found that lookup performance 
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Figure 13: Performance of name-tree lookups. This graph 
shows how the name-tree lookup performance of an INR goes 
down as the number of names in its name-tree increases. 



improved significantly for narrower name-specifiers, reaching 
several thousand lookups per second. 

These experiments give us a practical idea of how the 
base case b affects performance. We believe that this order- 
of-magnitude of lookup performance is adequate for intra- 
domain deployments, because of the load balancing provided 
by the INS self-organization protocol and the parallelism in- 
herent in independent name lookups. 

5.2 Name Discovery Performance 

One of the claims we made about INS was that it was capable 
of tracking rapid change and dynamism in services and hosts. 
This section substantiates this claim by discussing the perfor- 
mance of the name discovery protocol. 

We measured the performance of INS in discovering new 
network entities, which advertise their existence via name- 
specifiers. Figure 14 shows the average discovery time of a 
new name-specifier as a function of n, the number of hops in 
the INR network from the new name. The machines used in 
the experiments off-the-shelf Intel Pentium II 450 MHz PCs 
running Red Hat Linux 5.2 and Windows NT Server 4.0. The 
network nodes were connected over 100 Mbps Ethernet and 
10 Mbps wireless RF links. 

When an INR observed a new name-specifier from a pe- 
riodic node announcement, it processes the update message 
and performs a lookup operation on the name-tree to see if 
a route already exists. When it does not find the route, it 
grafts the name-specifier on to its name-tree and propagates 
a triggered-update to its neighbors. Thus, it is easy to see 
that the name discovery time in a network of identical INRs 
and links, T d (n) = n(T t + T g + T up + d), where 7] is the 
lookup time, T g is the graft time, T up is the update processing 
time, and d is the one-way network delay between any two 
nodes. That is, name discovery time is to first-order linear in 
the number of hops. The key experimental question is what 
the slope of the line is, because that determines how agile INS 
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Figure 14: Discovery time of a new network name. This graph 
shows that the time to discover a new network name is linear 
in the number of INR hops. 

is in tracking changes. 

In our experiments the structure of the name-tree on each 
INR was relatively constant (except for the new grafts), since 
we were not running any other applications in the system dur- 
ing the measurements. Thus, the lookup and graft times at one 
INR and the others were roughly the same. As shown in Fig- 
ure 14, Td(n) is indeed linear in n, with a slope of less than 
10 ms/hop. This implies that typical discovery times are only 
a few tens of milliseconds, and dominated by network trans- 
mission delays. 

6 Related Work 

We are unaware of an application-controlled network archi- 
tecture that integrates naming and routing the way the INS 
architecture does. We believe that the flexible naming and res- 
olution provided by INS is well-suited to the future Internet 
infrastructure because it enables a variety of network services 
and applications in an easily deployable manner. 

There has been significant research in wide-area naming 
and resolution, including some recent proposals. Vahdat et 
al. [40] present scheme for active names. Similar in spirit 
to active networks that incorporate general purpose compu- 
tation into the routing infrastructure [38, 44], active names 
allow applications to define arbitrary computation that exe- 
cutes on names at resolvers. We believe that active names are 
overly general and therefore complex; for many applications, 
the benefits they obtain can be accomplished using a flexible 
but non-Turing-complete naming system with a carefully cho- 
sen set of operators such as the one we have proposed. Fur- 
thermore, the active names scheme does not specify a resolu- 
tion protocol that incorporates message routing or name dis- 
semination for resource discovery. 

To our knowledge, the first proposal to decouple names 
from object locations was described in a paper by O'Toole and 
Gifford [30], where they describe a content naming scheme 



and its application to Semantic File Systems [18]. The de- 
sign of content names is very different from ours and so is its 
application, but the underlying philosophy is similar. 

Another suggestion similar to our intentional naming 
scheme was made by Jacobson [21]. Presented in the con- 
text of multicast-based self-configuring Web caching, the pro- 
posal was to use the URL namespace and "instead of ask- 
ing X to send you Y, simply ask for Y." More recently, as 
part of the Simple Systems DARPA ISAT group, Estrin et al. 
[14] suggested a naming scheme based on attributes to enable 
diffusion-based sensor tracking and control applications. Our 
intentional naming scheme has some features in common with 
that proposal, but differs in the details of the resolution and 
message routing processes and in the self-organization mech- 
anisms. 

Cisco's DistributedDirector [7] intelligently resolves ser- 
vice names (in the URL namespace) to the IP address of the 
closest server, based on client proximity and client-to-server 
link latency. Unlike our system, DistributedDirector is not a 
general framework for naming and resolution and it does not 
integrate resolution and routing the way INS does using inten- 
tional names. 

IBM's "T Spaces" [26] enable communication between ap- 
plications in a network by providing a lightweight distributed 
database model. Network entities can perform queries on 
pieces of data that are described by tuples (similar to attribute- 
value pairs in name-specifier expressions) and have been set 
by other entities. However, this system has been optimized 
for client-server applications rather than for (ad hoc) peer-to- 
peer communication, and uses a central database to maintain 
tuple mappings. Sun Microsystems' Jini project [22] aims to 
provide a framework for users to discover and access local 
services, by forming a "federation of networked devices" over 
Java's Remote Message Invocation (RMI). Jini does not ad- 
dress either how naming should be done or the name resolu- 
tion process. 

In the past few years, several schemes for distributed Web 
caching have been proposed including Harvest [6], Squid 
and the Internet Cache Protocol (ICP) [43], Adaptive Web 
Caching [2], diffusion-based caching [19], Summary Cache 
[15], Cisco's Cache Engine [8], Web caching using active 
networks [25], multicast-based caches [39], hierarchical Web 
caching [36], meta-data caching, etc. We believe that by be- 
ing able to incorporate data caching into the name resolution 
framework as an important optimization, INS has the poten- 
tial to simplify the complex problem of Web caching. Using 
INS would lead to an infrastructure similar to that described 
by Jacobson [21]. 

The Service Location Protocol (SLP) [41, 34] is a protocol 
designed to facilitate the discovery and use of heterogeneous 
network resources using centralized Directory Agents. In con- 
trast, INS enables highly robust, dynamic, and flexible entity 
(service) discovery. 
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Retaining network connectivity while mobile requires a 
level of indirection so that all traffic to the mobile host can 
be redirected to its current location. Mobile IP [33] achieves 
this using a Home Agent in the mobile host's home domain. 
With INS, the required level of indirection is obtained using 
the intentional naming system, since all traffic to the mobile 
host would go through a name resolution process. The tight 
integration of naming and routing enables continued network 
connectivity in the face of mobility. Furthermore, INS system 
is a highly distributed and fault tolerant architecture avoiding 
central points of failure that Mobile IP suffers from. A num- 
ber of protocols for ad hoc or infastructureless routing have 
recently been proposed [5, 31, 37]. These protocols, while 
very useful to enable IP connectivity, do not support routing 
of queries via name-specifiers like INS does. 

7 Concluding Remarks 

In this paper, we established the need for an intentional nam- 
ing scheme, where applications describe what they are look- 
ing for, not where to find data. We presented the design, im- 
plementation and evaluation of an Intentional Name System, 
called INS, to realize this vision. The components of INS in- 
clude the an intentional naming scheme using name-specifiers, 
which are query expressions in a restricted query language, an 
intentional name resolver architecture that resolve names and 
integrates naming and message routing, and the INS API and 
application architecture. 

We presented the design and analysis of an efficient algo- 
rithm for name lookups and measurements of our implemen- 
tation, which show that an (untuned) Java implementation can 
perform several hundred to a few thousand lookups per sec- 
ond. We also presented the design and evaluation of an en- 
tity discovery protocol, demonstrating INS' agility in tracking 
highly dynamic changes in network topology or application 
data. We discussed the details of an INR self-organization 
protocol that we use to bootstrap the system, form dynamic 
neighborhoods, and perform load management. 

Finally, we presented the design of the INS application ar- 
chitecture and detailed a sample mobile camera application 
for remote surveillance, which we have had experience with 
over the past many weeks. We detailed how this application 
used intentional names and leveraged INS' automatic support 
for mobility, group communication, service location and data 
caching. 

Our experience with INS has convinced us that using inten- 
tional names in the naming system provides the right level of 
indirection over which to implement a variety of services. Fur- 
thermore, although we have not explicitly detailed it, INS al- 
lows applications to efficiently track dynamic data attributes, 
because the choice of attributes to use in name-specifiers are 
completely under application-control. For example, a sensor 
application can use INS to send a message to all the temper- 



ature sensors in a building that have recently observed a tem- 
perature greater than some threshold, to actuate an action such 
as turning on air vents. We believe that INS has the potential to 
become an integral part of future device and sensor networks. 
Although our current experiences with INS are very encour- 
aging, there remain some important areas of fruitful research 
before the full benefits of this intentional naming architec- 
ture can be realized in the Internet. First, we need to care- 
fully expand the set of supported operators in the resolution 
process, such as incorporating range matches. Second, the 
current INS architecture is intended for intra-domain deploy- 
ment. We are actively developing a wide-area architecture to 
complement INS, which will integrate INS with extensions 
to DNS for ease of deployment. Ultimately, the benefits of 
such a system are in enabling or facilitating the development 
of new applications and services; to this end, we are design- 
ing new services (e.g., transparent performance-based server 
selection, location-dependent services, etc.) using INS. This 
will demonstrate the benefits of INS and help us characterize 
the class of applications that INS facilitates. 
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